Why might you keep conversation-turn embeddings in a separate, short-lived collection rather than mixing them into your main document knowledge base?

Conversation-turn embeddings and document knowledge base embeddings have fundamentally different characteristics, and mixing them in one collection creates problems in all three dimensions: lifecycle, relevance, and access. Lifecycle: document knowledge is long-lived and changes slowly, while conversation turns are ephemeral and should expire after hours or days. A single collection can only have one retention policy, so mixing them means either keeping conversations forever (wasting storage and potentially violating privacy) or expiring documents prematurely. Relevance: conversations are about what was just said, while documents are about what is known. A query that looks for context in a conversation should not compete with document chunks in the same vector space, because the two have different distributions and different retrieval intents. Access: conversation turns are typically accessible only to the participants, while documents may be broadly accessible. A single collection means the permission model has to handle both, which complicates the filter. Separate collections let you apply different retention, different indexing parameters, and different access controls to each.

The mechanism that makes separation beneficial is that a collection is the unit of configuration in Qdrant: the vector size, the distance metric, the HNSW parameters, the quantization, the replication factor, the shard count, and the optimizer thresholds all apply per collection. If documents and conversations need different configurations - for example, documents need high recall and conversations need low latency, or conversations need a shorter retention - they cannot share a collection without compromising on one or the other. Separating them also makes it possible to drop or snapshot the conversation collection independently, which is important for privacy and for cost control. And it makes the permission model simpler: the conversation collection can be scoped per user or per session, while the document collection has its own broader access rules. The retrieval pipeline can query both and merge the results, weighting them differently, without the two interfering in the index.

The trade-off is between the simplicity of one collection and the flexibility of two. A single collection is simpler to operate and to query - one search returns both types of results. Two collections require the application to query both and merge, which adds code and latency. The common mistake is to mix conversations into the document collection because it is easier, and then discover that conversations dominate the index (they accumulate quickly) and degrade document retrieval. The second mistake is to give the conversation collection the same retention as the document collection, which either wastes storage or loses conversations prematurely. The third mistake is to not separate access control, so a user can retrieve another user's conversation turns. The fourth mistake is to not consider the cost: conversations can be numerous and short, so the conversation collection may need a different sharding and optimizer configuration than the document collection. Version note: the per-collection configuration options in Qdrant have been stable, but the ability to set TTL on points or collections has evolved. Some versions support point-level expiration; others require application-level cleanup. Check the version's support for TTL before designing around it.

Version-dependent: Qdrant's support for point-level TTL and collection-level expiration has evolved. Some versions support an expires_at field or a TTL configuration; others require the application to periodically delete old points. If your version does not support TTL natively, the application must implement cleanup by filtering on a timestamp field and deleting in batches. The collection configuration options (HNSW, quantization, sharding) have been stable, but their defaults and the exact API shape have changed across releases.